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The PPP DES Encryption Protocol (DESE) 
Status of This Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 


The PPP Encryption Control Protocol (ECP) [2] provides a method to 
negotiate and utilize encryption protocols over PPP encapsulated 
links. 


This document provides specific details for the use of the DES 
standard [5, 6] for encrypting PPP encapsulated packets. 


Acknowledgements 


The authors extend hearty thanks to Fred Baker of Cisco for helpful 
improvements to the clarity of the document. 


Table of Contents 


TAELOAUCERON: (oe SF SS are See SS E Se PS eee eS aS ee Sack Sere 
ee MOBEVGE DON sass e te eo eile lee See So e es SS ee le Be Re Boe tee Se weigh we eee 
22, CONVENCIONS sre sai ala Sew Meee eS ee Be dad wa ts ceo ede Bede Sea e a E Scare Ode ores 
General ‘OVERVIEWS fe sie etaieed oR eaten Sh setik eee eben Sher bao a oie een ee ted: oat oe 
Structure stof Thus SpeciEeveatron se sih sate Bere ea Sa we Re SUSE 
DESE Configuration Operon. LOL ECP 4.6. cessed mieten gga eee es E S 
Packet Format- for DE SE aguar die ig shew ap did ee ea cers: Siler whan 4, ered ere eas 
ENGCEYPDELON sg tee adage, coe serene Me tet ote r a becca ph eserves aie Pa Seb gh gi Gear ete eae atte ne wee teh ty 
Padding HCONSLAISTACTONS: sire dened bi Aiea hah le Roe: a E a Pe E celal fed 
Generation of the Ciphertext 02 x Saw ee bed diis See eee Sas 
Retrieval of the Plaintext ec cee ew ee ee ee ee ee oe wee 
Recovery Vatter Packet LOSS: ous et e ary Siete cond a3 See ees Pare Bie cee 
MRU.. Considerations creiss t siete Fd eae eee dit hack ioe d Deh Se ae ota 


wild 
eae 
ons 
4. 


DADADAHARDUNBPWNHREREH 
ODMDADAADAUNHBWNNNNDN 


Sklower & Meyer Informational [Page 1] 


RFC 1969 PPP DES Encryption June 1996 


OF, IREFETEN CSS” chs tess vere eeu anhis eendl cles a A tel wlcek ouietig ever elvebel serie a E AEE 9 

10. Authors Addresses mar aria aaa Ca Seek one a Baga S ao Be a A Oe Sow AG 10 

Ile Expiraticn Date- -of CALS DESET cise < me a eee as esis eee gee 10 
1. Introduction 


1.1. Motivation 


The purpose of this memo is two-fold: to show how one specifies the 
necessary details of a "data" or "bearer" protocol given the context 
of the generic PPP Encryption Control Protocol, and also to provide 
at least one commonly-understood means of secure data transmission 
between PPP implementations. 


The DES encryption algorithm is a well studied, understood and widely 
implemented encryption algorithm. The DES cipher was designed for 
efficient implementation in hardware, and consequently may be 
relatively expensive to implement in software. However, its 
pervasiveness makes it seem like a reasonable choice for a "model" 
encryption protocol. 


Source code implementing DES in the "Electronic Code Book Mode" can 
be found in [7]. US export laws forbid the inclusion of 
compilation-ready source code in this document. 


1.2. Conventions 


The following language conventions are used in the items of 
specification in this document: 


fe) MUST, SHALL or MANDATORY -- the item is an absolute requirement 
of the specification. 


° SHOULD or RECOMMENDED -- the item should generally be followed 
for all but exceptional circumstances. 


fe) MAY or OPTIONAL -- the item is truly optional and may be 
followed or ignored according to the needs of the implementor. 


2. General Overview 


The purpose of encrypting packets exchanged between two PPP 
implementations is to attempt to insure the privacy of communication 
conducted via the two implementations. The encryption process 
depends on the specification of an encryption algorithm and a shared 
secret (usually involving at least a key) between the sender and 
receiver. 
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Generally, the encryptor will take a PPP packet including the 
protocol field, apply the chosen encryption algorithm, place the 
resulting cipher text (and in this specification, an explicit 
sequence number) in the information field of another PPP packet. The 
decryptor will apply the inverse algorithm and interpret the 
resulting plain text as if it were a PPP packet which had arrived 
directly on the interface. 


The means by which the secret becomes known to both communicating 
elements is beyond the scope of this document; usually some form of 
manual configuration is involved. Implementations might make use of 
PPP authentication, or the EndPoint Identifier Option described in 
PPP Multilink [3], as factors in selecting the shared secret. If the 
secret can be deduced by analysis of the communication between the 
two parties, then no privacy is guaranteed. 


While the US Data Encryption Standard (DES) algorithm [5, 6] provides 
multiple modes of use, this specification selects the use of only one 
mode in conjunction with the PPP Encryption Control Protol (ECP): the 
Cipher Block Chaining (CBC) mode. In addition to the US Government 
publications cited above, the CBC mode is also discussed in [7], 
although no C source code is provided for it per se. 


The initialization vector for this mode is deduced from an explicit 
64-bit nonce, which is exchanged in the clear during the negotiation 
phase. The 56-bit key required by all DES modes is established as a 
shared secret between the implementations. 


One reason for choosing the chaining mode is that it is generally 
thought to require more computation resources to deduce a 64 bit key 
used for DES encryption by analysis of the encrypted communication 
stream when chaining mode is used, compared with the situation where 
each block is encrypted separately with no chaining. Further, if 
chaining is not used, even if the key is never deduced, the 
communication may be subject to replay attacks. 


However, if chaining is to extend beyond packet boundaries, both the 
sender and receiver must agree on the order the packets were 
encrypted. Thus, this specification provides for an explicit 16 bit 
sequence number to sequence decryption of the packets. This mode of 
operation even allows recovery from occasional packet loss; details 
are also given below. 


3. Structure of This Specification 
The PPP Encryption Control Protocol (ECP), provides a framework for 


negotiating parameters associated with encryption, such as choosing 
the algorithm. It specifies the assigned numbers to be used as PPP 
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protocol numbers for the "data packets" to be carried as the 


associated "data protocol", 


and describes the state machine. 


Thus, a specification for use in that matrix need only describe any 
additional configuration options required to specify a particular 
algorithm, and the process by which one encrypts/decrypts the 
information once the Opened state has been achieved. 


4. DESE Configuration Option for ECP 


Description 


The ECP DESE Configuration Option indicates that the issuing 
implementation is offering to employ this specification for 

decrypting communications on the link, 
a request for its peer to encrypt packets in this manner. 


and may be thought of as 


The ECP DESE Configuration Option has the following fields, 
which are transmitted from left to right: 


Figure 1: 


0 
0 
+-+- 
| 
+ 


Type 


ECP DESE Configuration Option 


Length 


1, to indicate the DESE protocol. 


Length 


10 


Initial Nonce 


2 3 
7 8-9 0 F 23-4 5:67:38 9 O01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Initial Nonce .. 
—+-4+-4-4+-4+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+ 


This field is an 8 byte quantity which is used by the peer 
implementation to encrypt the first packet transmitted 
after the sender reaches the opened state. 


To guard against replay attacks, 
offer a different value during each ECP negotiation. An 
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example might be to use the number of seconds since Jan 
lst, 1970 (GMT/UT) in the upper 32 bits, and the current 
number of nanoseconds relative to the last second mark in 
the lower 32 bits. 


Its formulaic role is described in the Encryption section 
below. 


rmat for DESE 
n 


ESE packets themselves have the following fields: 


Figure 2: DES Encryption Protocol Packet Format 


0 1 2 3 

Os E5523) 4 9.46 TB: 9S O23 Ae. 6 8: O Oe I <2 3) AR 5.6.07 8: 9°01 
Fatt tata tata t ata AE Ai ata tata tata ttt att ata tatatatatatatatatat 
| Address | Control | 0000 | Protocol ID | 
Fatt tata tata t ata t ata tartatantata ttt tata tata tata tatatatatatatat 
| Seq. No. High | Seq. No. Low | Ciphertext 

Fatt ata ta tata tartar t arta tan tata tata ttt ata tata HMHHMHHMHHMHH 
Address and Control 


Proto 


Seque 


These fields MUST be present unless the PPP Address and 
Control Field Compression option (ACFC) has been 
negotiated. 


col ID 


The value of this field is 0x53 or 0x55; the latter 
indicates that ciphertext includes headers for the 
Multilink Protocol, and REQUIRES that the Individual Link 
Encryption Control Protocol has reached the opened state. 
The leading zero MAY be absent if the PPP Protocol Field 
Compression option (PFC) has been negotiated. 


nce Number 
These 16-bit numbers are assigned by the encryptor 


sequentially starting with 0 (for the first packet 
transmitted once ECP has reached the opened state. 
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Ciphertext 


The generation of this data is described in the next 
section. 


6. Encryption 


Once the ECP has reached the Opened state, the sender MUST NOT apply 
the encryption procedure to LCP packets nor ECP packets. 


If the async control character map option has been negotiated on the 
link, the sender applies mapping after the encryption algorithm has 
been run. 


The encryption algorithm is generally to pad the Protocol and 
Information fields of a PPP packet to some multiple of 8 bytes, and 
apply DES in Chaining Block Cipher mode with a 56-bit key K. 


There are a lot of details concerning what constitutes the Protocol 
and Information fields, in the presence or non-presence of Multilink, 
and whether the ACFC and PFC options have been negotiated, and the 
sort of padding chosen. 


Regardless of whether ACFC has been negotiated on the link, the 
sender applies the encryption procedure to only that portion of the 
packet excluding the address and control field. 


If the Multilink Protocol has been negotiated and encryption is to be 
construed as being applied to each link separately, then the 
encryption procedure is to be applied to the (possibly extended) 
protocol and information fields of the packet in the Multilink 
Protocol. 


If the Multilink Protocol has been negotiated and encryption is to be 
construed as being applied to the bundle, then the multilink 
procedure is to be applied to the resulting DESE packets. 


6.1. Padding Considerations 


Since the DES algorithm operates on blocks of 8 octets, packets which 
are of length not a multiple of 8 octets must be padded. This can be 
injurious to the interpretation of some protocols which do not 
contain an explicit length field in their protocol headers. 
(Additional padding of the ciphered packet for the purposes of 
transmission by HDLC hardware which requires an even number of bytes 
should not be necessary since the information field will now be of 
length a multiple of 8, and whether or not the packet is of even 
length can be forced by use or absence of a leading zero in the 
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protocol field). 


For protocols which do have an explicit length field, such as IP, 

IPX, XNS, and CLNP, then padding may be accomplished by adding random 
trailing garbage. Even when performing the Multilink protocol, if it 
is only being applied to packets with explicit length fields, and if 
care is taken so that all non-terminating fragments (i.e., those not 
bearing the (E)nd bit) are of lengths divisible by 8; then no ill 
effects will happen if garbage padding is applied only to terminating 
fragments. 


For certain cases, such as the PPP bridging protocol when the 
trailing CRC is forwarded or when any bridging is being applied to 
protocols not having explicit length fields, adding garbage changes 
the interpretation of the packet. The self-describing padding option 
[4] permits unambiguous removal of padded bytes; although it should 
only be used when absolutely necessary as it may inadvertently 
require adding as many as 8 octets to packets that could otherwise be 
left unaltered. 


Consider a packet, which by unlucky circumstance is already a 
multiple of 8 octets, but terminates in the sequence 0x1, 0x2. 
Self-describing padding would otherwise remove the trailing two 
bytes. For purposes of coexistence with archaic HDLC chips where 
it is necessary to transmit packets of even length, one would 
normally only have to add an additional two octets (0x1, 0x2), 
which could then be removed. However, since the packet was 
initially a multiple of 8 bytes, an additional 8 bytes would need 
to be added. 


6.2. Generation of the Ciphertext 


In this discussion, E[k] will denote the basic DES cipher determined 
by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the 
corresponding decryption mechanism. The padded plaintext described 
in the previous section then becomes a sequence of 64 bit blocks P[i] 
(where i ranges from 1 ton). The circumflex character (^) 
represents the bit-wise exclusive-or operation applied to 64-bit 
blocks. 


When encrypting the first packet to be transmitted in the opened 
state let C[0] be the result of applying E[k] to the Initial Nonce 
received in the peer’s ECP DESE option; otherwise let C[0] be the 
final block of the previously transmitted packet. 
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The ciphertext for the packet is generated by the iterative process 


Cli] = E[k] (P[i] ^ C[i-1]) 
for i running between 1 and n. 
6.3. Retrieval of the Plaintext 


When decrypting the first packet received in the opened state, let 
C[0] be the result of applying E[k] to the Initial Nonce transmitted 
in the ECP DESE option. The first packet will have sequence number 
zero. For subsequent packets, let C[0] be the final block of the 
previous packet in sequence space. Decryption is then accomplished 
by 


P[i] = C[i-1] ^ D[k] (C[il), 
for i running between 1 and n. 
6.4. Recovery after Packet Loss 


Packet loss is detected when there is a discontinuity in the sequence 
numbers of consecutive packets. Suppose packet number N - 1 has an 
unrecoverable error or is otherwise lost, but packets N and N + 1 are 
received correctly. 


Since the algorithm in the previous section requires C[0] for packet 
N to be C[last] for packet N - 1, it will be impossible to decode 
packet N. However, all packets N + 1 and following can be decoded in 
the usual way, since all that is required is the last block of 
ciphertext of the previous packet (in this case packet N, which WAS 
received). 


7. MRU Considerations 


Because padding can occur, and because there is an additional 
protocol field in effect, implementations should take into account 
the growth of the packets. As an example, if PFC had been 
negotiated, and if the MRU before had been exactly a multiple of 8, 
then the plaintext resulting combining a full sized data packets with 
a one byte protocol field would require an additional 7 bytes of 
padding, and the sequence number would be an additional 2 bytes so 
that the information field in the DESE protocol is now 10 bytes 
larger than that in the original packet. Because the convention is 
that PPP options are independent of each other, negotiation of DESE 
does not, by itself, automatically increase the MRU value. 
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8. Security Considerations 


Security issues are the primary subject of this memo. This proposal 
relies on exterior and unspecified methods for authentication and 
retrieval of shared secrets. 


It proposes no new technology for privacy, but merely describes a 
convention for the application of the DES cipher to data transmission 
between PPP implementation. 


Any methodology for the protection and retrieval of shared secrets, 
and any limitations of the DES cipher are relevant to the use 
described here. 
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